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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document is part 3 of a multi-part deliverable covering the Network and Service Management; Subscription 
Management, as identified below: 

Part 1: "Requirements"; 

Part 2: "Information Model" ; 

Part 3: "Functional Architecture". 



Introduction 

The focus of the present document is the definition of the Subscription Management (SuM) Functional Architecture that 
has the objective to offer service providers and operators means for a simple, flexible and efficient subscription data 
repartition in the TISPAN NGN network entities. 
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Scope 



The purpose of the SuM Functional Architecture is the design of the NGN OSS Service Interfaces (NOSIs) needed for 
the management of a specific Subscriber, User, Service Profile and User Services within TISPAN NGN. The SuM 
Functional Architecture shall deliver the necessary NOSIs for the Resource Provisioning and Service Activation 
processes. 

The NOSIs related to Service Configuration & Activation shall be network technology agnostic without any knowledge 
of the NGN functional entities that are involved. The NOSIs related to Resource Provisioning are responsible of NGN 
functional entities (including CPE and AS) management and shall hide the complexity of the different NGN functional 
entities to the NOSIs related to Service Configuration & Activation. 

The specification of the NOSIs comprises the list of operations they are offering and the associated subscription and 
user data that are specified in the SuM Information model. The set of NGN FEs expose one or more NOSIs for the 
management of Subscription Management data. 

The present document is part of specifications related to subscription management that comprises: 

• TS 188 002-1 [2]: SuM Requirements. 

• TS 188 002-2 [3]: SuM Information Model. 

• TS 188 002-3 (the present document): SuM Functional Architecture. 

The present document is developed according to the specifications of TISPAN Rl, including the NGN OSS 
Architecture specifications described in TS 188 001 [1]. The SuM Functional Architecture meets the requirements of 
TS 188 002-1 [2]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI TS 188 001: "Telecommunications and Internet Converged Services and Protocols for 
Advanced Networking (TISPAN); NGN management; OSS Architecture Release 1". 

[2] ETSI TS 188 002-1: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Subscription Management; Part 1: Requirements". 

[3] ETSI TS 188 002-2: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Subscription Management; Part 2: Information Model". 

[4] ETSI TS 122 240: "Universal Mobile Telecommunications System (UMTS); Service requirements 

for 3GPP Generic User Profile (GUP); Stage 1 (3GPP TS 22.240 Release 6)". 

[5] ETSI TS 123 240: "Universal Mobile Telecommunications System (UMTS); 3GPP Generic User 

Profile (GUP) requirements; Architecture (Stage 2) (3GPP TS 23.240 Release 6)". 

[6] ETSI TR 123 941: "Universal Mobile Telecommunications System (UMTS); 3GPP Generic User 

Profile (GUP); Stage 2; Data Description Method (DDM) (3GPP TR 23.941 Release 6)". 

[7] ETSI TS 129 240: "Universal Mobile Telecommunications System (UMTS); 3GPP Generic User 

Profile (GUP); Stage 3; Network (3GPP TS 29.240 Release 6)". 

[8] ETSI TS 132 171: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Teleconmiunications System (UMTS); Telecommunication management; Subscription 
Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP): 
Requirements (3GPP TS 32.171)". 

[9] 3GPP TS 32.172: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; Telecommunication management; Subscription Management (SuM) Network 
Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS) (Release 8)". 

[10] ETSI TS 132 175: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Subscription 
Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP): 
extensible Markup Language (XML) definition (3GPP TS 32.175)". 

2.2 Informative references 

[II] ETSI TS 132 101: "Universal Mobile Telecommunications System (UMTS); Telecommunication 
management; Principles and high level requirements (3GPP TS 32.101)". 

[12] ETSI TS 132 150: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Integration Reference 
Point (IRP) Concept and definitions (3GPP TS 32.150)". 

[13] ETSI TS 132 311: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Generic Integration 
Reference Point (IRP) management; Requirements (3GPP TS 32.311)". 

[14] ETSI TS 132 312: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Generic Integration 
Reference Point (IRP) management; Information Service (IS) (3GPP TS 32.312)". 

[15] ETSI TS 132 317: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Generic Integration 
Reference Point (IRP) management; SOAP Solution Set (SS) (3GPP TS 32.317)". 
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[16] ETSI TS 132 301: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Notification Integration Reference Point (IRP): Requirements 
(3GPPTS 32.301)". 

[17] ETSI TS 132 302: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Notification Integration Reference Point (IRP): Information Service (IS) 
(3GPPTS 32.302)". 

[18] ETSI TS 132 307: "Universal Mobile Telecommunications System (UMTS); Telecommunication 

management; Configuration Management (CM); Notification Integration Reference Point (IRP): 
Simple Object Access Protocol (SOAP) Solution Set (SS) (3GPP TS 32.307)". 

[19] ETSI TS 132 661: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Kernel CM; Requirements (3GPP TS 32.661)". 

[20] ETSI TS 132 662: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Kernel CM; Information service (IS) (3GPP TS 32.662)". 

[21] ETSI TS 132 665: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Kernel CM Integration Reference Point (IRP): extensible Markup Language 
(XML) definitions (3GPP TS 32.665)". 

[22] ETSI TS 132 667: "Universal Mobile Telecommunications System (UMTS); Telecommunication 

management; Configuration Management (CM); Kernel CM Integration Reference Point (IRP): 
Simple Object Access Protocol (SOAP) Solution Set (SS) (3GPP TS 32.667)". 

[23] ETSI TS 132 601: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Basic CM Integration Reference Point (IRP); Requirements 
(3GPPTS 32.601)". 

[24] ETSI TS 132 602: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Basic CM Integration Reference Point (IRP): Information Service (IS) 
(3GPPTS 32.602)". 

[25] ETSI TS 132 607: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Basic CM Integration Reference Point (IRP): SOAP Solution Set (SS) 
(3GPPTS 32.607)". 

[26] ETSI TS 132 621: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Generic network resources Integration Reference Point (IRP); Requirements 
(3GPPTS 32.621)". 

[27] ETSI TS 132 622: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Generic network resources Integration Reference Point (IRP): Network 
Resource Model (NRM) (3GPP TS 32.622)". 

[28] ETSI TS 132 625: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Configuration 
Management (CM); Generic network resources Integration Reference Point (IRP): Bulk CM 
extensible Markup Language (XML) file format definition (3GPP TS 32.625)". 

[29] W3C Recommendation: "XML Path Language (XPath)" Version 1.0, 16 November 1999. 
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3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CLF Connectivity session Location and repository Function 

GUP Generic User Profile 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

NASS Network Attachment Subsystem 

NGN FE NGN Functional Entity 

NOSI NGN OSS Service Interface 

OSS Operation Support Systems 

PDBF Profile Data Base Function 

RAF Repository Access Function 

RP Resource Provisioning 

SCA Service Configuration & Activation 

SOAP Simple Object Access Protocol 

SS Solution Set 

SuM Subscription Management 

TOM Telecommunication Operation Map 

UPSF User Profile Server Function 

WSDL Web Services Description Language 

XML extensible Markup Language 



SulVI Functional Architecture 



4.1 



Overview 



Subscription Management is paramount for the NGN service delivery within TISPAN NGN. It aims to define an end- 
to-end information model and a functional architecture that allows service providers to provision their NGN functional 
entities with all the mandatory/optional information specific to a subscriber and its users. Subscription Management can 
be summarized as the framework that offer service providers means for efficient management of all the data related to a 
specific subscription. The purposes of specifying a SuM Information Model is to capture all the information needed for 
the management of a specific subscription. The purpose of the SuM Functional Architecture is the design of the NGN 
OSS Service Interfaces (NOSIs) needed for the management of subscribers and their users, with respect to the 
requirements defined in [2], and to the NGN OSS Architecture [1]. 

Subscription Management aligns with subset of the eTOM fulfilment process, in particular the Customer Relationship 
Management process, the Service Management & Operations process, and the Resource management and operation 
process. As depicted in figure 1, the current target of the SuM FA is the specification of: 

• The NOSIs for the reaHzation of the Service Configuration & Activation (SCA NOSIs). 

• The NOSIs for the realization of the Resource Provisioning (RP NOSIs). 

• The NOSIs exposed for the management of data stored within NGN FEs (NGN FE NOSIs). 
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Order Handling 




Service Configuration 
& Activation (SCA) 



Resource Provisioning (RP) 



GN Function Entities 




NOSI Interface 



Figure 1: Subscription Management NOSI 

Following concepts are introduced: 

• SCA Service (SCA): Service which exposes at least one SCA NOSI. 

• RP Service (RP): Service which exposes at least one RP NOSI. 

• NGN FE Service (NGN FE MA): Service which exposes at least one NGN FE NOSI. 

The following figure depicts the Subscription Management Functional Architecture based on the precedent concepts 
and TISPAN NGN OSS Architecture. 




NGN OSS Basic 
Framework Services 





Common Communication Veliicle 





T 
T 
T 

T 



NOSI exposed for the management of data stored in NGN FE 

RPNOSI 

SCA NOSI 

NGN OSS Basic Frameworl< Services NOSIs 



Figure 2: Subscription Management NOSIs 
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The NGN OSS basic framework services NOSIs are the NOSIs in charge of aspects such as distribution, transparency, 
registration, etc., as described in NGN OSS Architecture. The NGN OSS basic framework services NOSIs are out of the 
scope of the Subscription Management standards. 

4.2 Service Configuration and Activation 

For the specification of the SCA NOSIs, it is necessary to Hst all the required capabilities that need to be supported or 
offered by the NOSIs with respect to SuM requirements, eTOM and to the use cases defined in [2]. There is no 
assumption on the relations between the required capabilities and the NOSIs that support them. 

The SCA NOSIs shall expose the following capabilities: 

• Manage Subscription by the service provider: consist in all the CRUD operations needed for the 
management of a specific subscription. 

• Manage Subscription by the subscriber: consist in all the CRUD operation allowed by the service provider 
for its subscribers (example: subscribe to new services, etc.). 

• Manage Users: consist in all the CRUD capabilities needed for the management of a user of a specific 
subscriber, (example: create new user, assign services to a user, etc.). 

• Manage User Services: consist in all the capabilities needed for the customization of services by users 
(example: configure a phone number for the call forwarding service, etc.). 

In addition to the above capabilities, the SCA NOSI shall expose the subscribe/notify capabilities that allows 
notifications when subscription information change (example: when a phone number for the call forwarding service is 
configured by a user, the service provider may be informed for legal interception purposes). 

The precedent capabilities of the SCA NOSIs represent the fact that theses NOSIs are responsible of the management of 
Subscriber, Subscription and Users. 



4.3 Resource Provisioning 



This clause consists in a description of all the capabilities required for SuM within the Resource Provisioning process 
group with respect to the Subscription Management Requirements and to eTOM. 

For the specification of the RP NOSIs, it is necessary to list all the required capabilities that need to be supported or 
offered by the NOSIs with respect to eTOM and to the use cases defined in [2] . 

The RP NOSIs shall expose the following capabilities: 

• Manage NGN Subscription Management Data: consist in all the CRUD capabiHties related to the 
management of Subscription Management information (services, network access, credentials, etc.) for 
subscription, users, and user services. 

The precedent capabilities represent the fact that the RP NOSIs allow the management of the information part of the 
Subscriber, Subscription and Users which are the Services, Credentials, Network Access, etc. 

4.4 NGN Functional entities 

This clause consists in a description of all the capabilities required for SuM within the NGN Functional entities with 
respect to the Subscription Management Requirements and to eTOM. 

The TISPAN NGN Functional entities concerned by the present SuM NGN FEs NOSI specification are: 

• The UPSF. 

• The PDBF, NACF and the CLF in the NASS subsystem. 

• User data repositories of Application servers offering NGN services. 
NOTE: The CPE case is for further study. 
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The Operations offered by NGN FE NOSIs allows to create, read, update and delete subscription data stored on any 
instance of the concerned NGN FEs. 

These operations are not different from a NGN FE to another, so the specifications of these operations are common to 
all the NGN FEs. They comprise: 

• "Create" operation: it applies to a data that is created on the concerned NGN FE. It indicates the links or 
references that this data can have with other data. 

• "Read" operation: it allows to retrieve a data stored on a given NGN FE, by using the relevant identifier of this 
data. 

• "Update" operation: it allows to update a data, its attributes or its links to other data. 

• "Delete" operation: it allows to delete a data and its dependent data ("children"). 
These operations are completed with the following ones: 

• "Notify" operations: it allows the NGN FE to notify modifications occurring on data to the Resource 
Management. 

• "Subscribe/ unsubscribe to notify": it allows the Resource Management to be (/ or not) notified of 
modifications occurring on data stored on the NGN FE. 



SuM NOSI 



In this clause, a description of the process used for the identification and specification of the SUM NOSI is given. In 
addition, a description of the relationship between the SuM NOSI and the SuM Information model is also given. 

A NGN OSS Service Interface (NGN OSS SI) is defined in the NGN OSS Architecture [1], clauses 3 and 6.3. It is a 
well defined grouping of related NGN OSS Operations and constant data which are necessary to deliver coherent 
business or system functionality. The NGN OSS Service Interface is: 

• An aggregation of functionality required for managing some coherent aspect of the NGN network or services. 
This functionality is provided through a set of related behaviour/functionality and is made publicly available 
for use by consumers of this service interface. An example is an Alarm Reporting service interface that offers 
the functionality supporting the NGN OSS Operations "getAlarmList" and "acknowledge Alarms". 

• Comprised of a set of NGN OSS Operations which must be all present. 

According to the above definition from [1], a NOSI is a set of operations and constant data, which correspond to an 
aggregation of functionality required for managing aspects of NGN network or services. 

With respect to this definition, we will first describe the methodology used for the identification of the NOSIs needed 
for Subscription Management, and the NOSI themselves with their operations. We will then detail the relationship 
between the NOSIs and the Subscription Management Information Model which represent the data part of the NOSI. 

5.1 SuM NOSI Identification 

In this clause, a description of the process used for the identification and specification of the SUM NOSI is given. 

In clause 4, we have identified three sets of NOSI for Subscription Management: SCA, RP and NGN FE NOSIs and the 
capabilities they should expose. 

The SCA NOSI should expose capabilities for the management of subscriber, subscription and users. The RP NOSI 
should expose capabilities for the management of the information part of the Subscriber, subscription and users which 
are the Services, Credentials, Network Access, etc. 

The NGN FE NOSIs shall expose the capabilities for the basic CRUD operations on the subscription management 
information contained in the NGN FE(s). 

The following NOSI have been identified. 
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SCA NOSI 


Operations 


Manage Subscription by Service Provider (SCA-IVISSP) 


- Create/ Read/Update/ Delete Subscription 

- Subscribe/Notify operations may be defined 


IVIanage Subscription by Subscriber (SCA-IVISS) 


- Read/Update Subscription 

- Subscribe/Notify operations may be defined 


IVIanage User(SCA-IVIU) 


- Create/Read/Update/Delete User 

- Subscribe/Notify operations may be defined 


IVIanage User Services(SCA-MUS) 


- Create/Read/Update/Delete User Services 

- Subscribe/Notify operations may be defined 



RP NOSI 




Subscription Services (RP-SS) 


- Configure/Update/Read/Remove subscription and user information 

- Subscribe/Notify operations may be defined 


User Preferences (RP-UP) 


- Configure/Update/Read/Remove Preferences for user 

- Subscribe/Notify operations may be defined 


Subscription Network Access (RP- SNA) 


- Configure/Update/Read/Remove Network Access for user/subscription 

- Subscribe/Notify operations may be defined 



NGNFE 


Operations 


Manage Data (NGN FE-MD) 


- Create/ Read/Update/ Delete Data 

- Subscribe/Notify operations may be defined 



5.2 



SuM NOSI and SUM Information Model 



In this clause, a description of the relationship between the SuM NOSI and the SuM Information model is also given. A 
NOSI is a well defined grouping of related NGN OSS Operations and constant data. In clause 5.1 we have identified a 
set of NOSIs with their related operations. The constant data that are part of a NOSI is part of the Subscription 
Management Information Model. 

A NOSI as defined in NGN OSS Architecture is equivalent to the SOA service interface concept. In the OASIS SOA 
reference model which is used as the reference in TISPAN, service interface is defined as the means for interacting with 
a service (an SOA service is accessed by means of a service interface, where the interface comprises the specifics of 
how to access the underlying capabilities). A service is opaque in that its implementation is typically hidden from the 
service consumer except for the information and behaviour models exposed through the service interface and the 
information required by service consumers to determine whether a given service is appropriate for their needs. 

An SOA service interface includes the specific protocols, commands, and information exchange by which actions are 
initiated that result in the real world effects as specified through the service functionality portion of the service 
description. The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. 

These prescribe what information needs to be provided to the service in order to access its capabilities and interpret 
responses. This is often referred to as the service's information model. 

The information model of a service is a characterization of the information that may be exchanged with the service. 
Only information and data that are potentially exchanged with a service are generally included within that service's 
information model. The scope of the information model includes the format of information that is exchanged, the 
structural relationship within the exchanged information and also the definition of terms used. 

According to the OASIS service interface and its information model definitions, we define the relation between the 
SuM NOSI and the SuM information Model as follows: "The Information model of a SuM NOSI should be a part of the 
whole SuM Information Model". 

For example, if the SuM Information Model define 3 objects (object A, object B, object C), their attributes and relations 
between the 3 objects, a specific SuM NOSI may use only 2 objects (Object A and Object C) with all their attributes an 
relations between the 2 objects as defined in the SuM Information Model. 

In summary, for each SuM NOSI, its associated part of the SuM Information Model should be indicated. For example, 
the NOSIs exposed by the SCA may access only to information that represents subscription, user, service profiles and 
services which are independent from the network resources. 
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The association between the NOSIs and the information model or information part of the information model which is 
accessed by a specific NOSI is defined in clauses 6, 7 and 8. 

5.3 SuM NOSI description 

The following table is used to describe the SuM NOSIs in clauses 6, 7 and 8. 



Operation 


contains the name of a NOSI operation 


Description 


describes the purpose of a NOSI operation 


Pre-conditions 


defines the conditions to be fulfilled before requesting a NOSI operation 


Post-conditions 


defines the new conditions after the execution of a NOSI operation 


SulVI Info IVIodel related Inputs 


as according to clause 5.2, data inputs defined for a NOSI operation are part of the 
SuM info model, and are identified through the relevant Information Object Classes 
(IOC) of the SuM info model to which they refer or belong 


SuM Info Model related Outputs 


as according to clause 5.2, data outputs defined for a NOSI operation are part of the 
SuM info model, and are identified through the relevant Information Object Classes 
(IOC) of the SuM info model to which they refer or belong 



NOTE 1 : The outputs parameters are those delivered when the request is successful. Exception cases are not 
covered in this release. 

NOTE 2: Subscribe to notify / notify operations are not described in this release. 



6 SuM Service Activation and Configuration NOSIs 

This clause contains the description of the SuM Service Configuration & Configuration NOSIs identified in clause 5.1. 

NOTE: Since both the TISPAN SCA-NOSI and MTOSI Interfaces from TMF mTOP in the Service Activation 
domain specify interfaces between the eTOM's Order Handling process in the CRM layer and the SCA 
process in the Service Management layer, a possible further harmonization and alignment 
between these standards in the offered functionalities as well as the interfaces and the associated 
information model will be investigated. 

A mutual further study as to the potential benefits of using MTOSI Service Activation Interface as SCA 
NOSIs has been offered and possible advantages from alignment with MTOSI Service Activation 
Interfaces will be explored with mTOP's MTOSI SAI team. 

6.1 Manage Subscription by Service Provider (SCA-MSSP) 

The SCA-MSSP NOSI is dealing with the following part of the SuM Info model: 

• SuMSubscriberProfile IOC. 

• SuMService lOCs. 

• SuMSubscribedServiceGroup IOC. 

• SuMSubscribedService lOCs. 

NOTE 1: The subclasses of the SuMSubscribedService and SuMService lOCs are involved in the SCA process. 

These classes contain also attributes belonging to the Resource Provisioning process, and the implications 
of this are for further study. 

NOTE 2: An instance of the SumSubscribedServicesGroup IOC may identify a subscription with multiple 
subscribed services. 
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Operation 


SCA-MSSP Create Subscription 


Description 


Create a subscription with associated subscribed services 


Pre-conditions 


Subscriber exists 


Post-conditions 


The subscription with its set of subscribed services has been created 


SulVI Info IVIodel related Inputs 


SulVISubscriberProfile IOC, SulVIService lOCs 


SuM Info Model related Outputs 


SulVISubscribedServiceGroup IOC, SulVISubscribedService lOCs 



Operation 


SCA-IVISSP Delete Subscription 


Description 


Delete a subscription with associated subscribed services 
NOTE: This operation should also suppress / modify all User Service profiles 
concerned by subscribed services that are suppressed. 


Pre-conditions 


Subscriber and subscribed services exists 


Post-conditions 


The subscription with its set of subscribed services has been deleted 


SuM Info Model related Inputs 


SuMSubscribedServiceGroup IOC 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MSSP Update Subscription 


Description 


Update a subscription and/or associated subscribed services. It can comprise 
addition, deletion and modification of a service 


Pre-conditions 


Subscriber and subscription exists 


Post-conditions 


The subscription with its set of subscribed services has been modified 


SuM Info Model related Inputs 


SuMSubscribedServiceGroup IOC, SuMSubscribed Service lOCs 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MSSP Read Subscription 


Description 


Read a subscription and associated subscribed services 


Pre-conditions 


Subscriber and subscription exists 


Post-conditions 


No modification 


SuM Info Model related Inputs 


SuMSubscribedServiceGroup IOC, SuMSubscribed Service lOCs 
NOTE: According to the input, the read operation may concern the whole set of 
subscribed services or only a part. 


SuM Info Model related Outputs 


SuMSubscribedServiceGroup IOC, SuMSubscribed Service lOCs 



6.2 Manage Subscription by Subscriber (SCA-MSS) 

The SCA-MSS NOSI is dealing with the following part of the SuM Info model: 

• SuMSubscriberProfile IOC. 

• SuMService IOC. 

• SuMSubscribedServiceGroup IOC. 

• SuMSubscribedService lOCs. 

NOTE 1: The subclasses of the SuMSubscribedService and SuMService lOCs are involved in the SCA process. 

These classes contain also attributes belonging to the Resource Provisioning process, and the implications 
of this are for further study. 

NOTE 2: The SCA-MSS operations are similar to the SCA-MSSP ones but the behaviour would be different 
according to what the subscriber is allowed to do. 



Operation 


SCA-MSS Create Subscription 


Description 


Create a subscription with associated subscribed services 


Pre-conditions 


Subscriber exists 


Post-conditions 


The subscription with its set of Subscribed services has been created 


SulVI Info Model related Inputs 


SulVISubscriberProfile IOC, SuMService lOCs 


SuM Info Model related Outputs 


SuMSubscribedServiceGroup IOC, SuMSubscribedService lOCs 
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Operation 


SCA-MSS Delete Subscription 


Description 


Delete a subscription with associated subscribed services 


Pre-conditions 


Subscriber and subscribed services exists 


Post-conditions 


The subscription with its set of Subscribed services has been deleted 


SulVI Info IVIodel related Inputs 


SuMSubscriberProfile IOC, SuMSubscribedServiceGroup IOC 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MSS Update Subscription 


Description 


Update a subscription and/or associated subscribed services. It can comprise 
addition, deletion and modification of a service 


Pre-conditions 


Subscriber and subscription exists 


Post-conditions 


The subscription with its set of Subscribed services has been modified 


SuM Info Model related Inputs 


SuMSubscriberProfile IOC, SuMService lOCs, SuMSubscribedServiceGroup IOC, 
SuMSubscribedService lOCs 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MSS Read Subscription 


Description 


Read a subscription and associated subscribed services 


Pre-conditions 


Subscriber and subscription exists 


Post-conditions 


No modification 


SuM Info Model related Inputs 


SuMSubscriberProfile IOC, SuMSubscribedServiceGroup IOC, 
SuMSubscribedService IOC 


SuM Info Model related Outputs 


SuMSubscribedServiceGroup IOC, SuMSubscribed Service lOCs 



6.3 Manage User(SCA-MU) 

The SCA-MU NOSI is dealing with the following part of the SuM Info model: 

• SuMSubscriberProfile IOC. 

• SuMUser IOC. 



Operation 


SCA-MU Create User 


Description 


Create User with user general characteristics 

NOTE: This operation does not assign any service to the user. In practice, a user 

is at least associated to one service that will be achieved through the 

SCA MUS NOSI. 


Pre-conditions 


Subscriber exists 


Post-conditions 


The user has been created 


SuM Info Model related Inputs 


SuMSubscriber IOC, 
SuMUser IOC 


SuM Info Model related Outputs 


SuMUser IOC 



Operation 


SCA-MU Delete User 


Description 


Delete a user 

NOTE: This operation should also suppress all SuM Service profiles attached to 
the user. 


Pre-conditions 


Subscriber exists 


Post-conditions 


The user and its associated User Service profiles have been deleted 


SuM Info Model related Inputs 


SuMUser IOC 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MU Update User 


Description 


Update the profile of a user 


Pre-conditions 


Subscriber and User exist 


Post-conditions 


User updated 


SuM Info Model related Inputs 


SuMUser IOC 


SuM Info Model related Outputs 


None identified 
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Operation 


SCA-MU Read User 


Description 


Read the profile of a user 


Pre-conditions 


Subscriber and User exist 


Post-conditions 


No modification 


SulVI Info IVIodel related Inputs 


SuMUser IOC 


SuM Info Model related Outputs 


SuMUser IOC 



6.4 Manage User Services(SCA-MUS) 

The SCA-MU NOSI is dealing with the following part of the SuM Info model: 

• SuMUser IOC. 

• SuMSubscribedService lOCs. 

• SuMServiceProfile lOCs (IMSServiceProfile IOC, ApplicationServiceProfile IOC, NgnNetworkAccessProfile 
IOC). 

NOTE 1 : The subclasses of the SuMSubscribedService and SuMServiceProfile lOCs are involved in the SCA 
process. These classes contain also attributes belonging to the Resource Provisioning process, and the 
implications of this are for further study. 



Operation 


SCA-MUS Create User Services 


Description 


Assign subscribed services to the user 


Pre-conditions 


Subscriber, subscription with subscribed services, user exist 


Post-conditions 


The user with its service profiles for subscribed services has been provisioned 
The execution of this operation will create related instances of SuMServiceProfile 
IOC subclasses according to the SuMSubscribedService instances 


SuM Info Model related Inputs 


SuMUser IOC, SuMSubscribedService lOCs, NgnSuMCredentials IOC 


SuM Info Model related Outputs 


None identified 



NOTE 2: The handling of credentials through this NOSI is for further study. 



Operation 


SCA-MUS Delete User Services 


Description 


Delete services assigned to a user 


Pre-conditions 


Subscriber, user and User Service profiles exist 


Post-conditions 


The concerned user services have been deleted 

The execution of this operation will delete related instances of SuMServiceProfile 

IOCS 


SuM Info Model related Inputs 


SuMUserlOC, SuMServiceProfile lOCs 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MUS Update User Services 


Description 


Update user services 


Pre-conditions 


Subscriber, user and User Service profiles exist 


Post-conditions 


The services assigned to the user have been modified 

The execution of this operation will update related instances of SuMServiceProfile 

lOCs in the respect of subscribed services 


SuM Info Model related Inputs 


SuMUser IOC, SuMSubscribedService lOCs, SuMServiceProfile lOCs 


SuM Info Model related Outputs 


None identified 



Operation 


SCA-MUS Read UserServices 


Description 


Read user services 


Pre-conditions 


Subscriber, user and User Service profiles exist 


Post-conditions 


No modification 


SuM Info Model related Inputs 


SuMUser IOC, SuMServiceProfile lOCs 


SuM Info Model related Outputs 


SuMServiceProfile lOCs 
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7 



SuM Resource Provisioning NOSI 



This clause contains the description of the SuM Resource Provisioning NOSIs identified in clause 5.1. 

7.1 Subscription Services (RP-SS) 

The RP-SS NOSI is dealing with the following part of the SuM Info model: 

• SuMUser IOC. 

• SuMServiceProfile lOCs (IMSServiceProfile, Applications erviceProfile), User Servicelnstance lOCs, 
NgnSuMCredentials IOC, IMSPubHcIdentification lOCs. 

NOTE: The lOCs here listed are all associated to the user and to the services of a subscription that are assigned to 
the user. It is not here considered there may be other data associated to the subscription, but not to the 
user. 



Operation 


RP-SS Configure Subscription Services 


Description 


Configure subscription and user information related to IIVIS, and Applications, (it 
does not concern NGN network Access) 


Pre-conditions 


Subscriber, subscription with subscribed services, user exist 


Post-conditions 


The user with its service profiles has been configured 


SulVI Info IVIodel related Inputs 


SuMUserlOC, SumServiceProfile lOCs (IMSServiceprofile IOC, 
ApplicationServiceProfile IOC), UserServicelnstance IOC, NgnSuMCredentials IOC, 
IMSPubHcIdentification lOCs 


SuM Info Model related Outputs 


None identified 



Operation 


RP-SS Remove Subscription Services 


Description 


Remove subscription and user information related to IMS service and Application 
services 


Pre-conditions 


Subscriber, user and User Service profiles exist 


Post-conditions 


The user services profiles have been deleted 


SuM Info Model related Inputs 


SuMUser IOC, SumServiceProfile lOCs (IMSServiceProfile IOC, 
ApplicationServiceProfile IOC), UserServicelnstance lOCs, NgnSuMCredentials 
IOC, IMSPubHcIdentification IOC 


SuM Info Model related Outputs 


None identified 



Operation 


RP-SS Update Subscription Services 


Description 


Update subscription and user information related to IMS services and Application 
services 


Pre-conditions 


Subscriber, user and user service profiles exist 


Post-conditions 


The user services profiles have been updated 


SuM Info Model related Inputs 


SuMUser IOC, SumServiceProfile lOCs (IMSServiceprofile IOC, 
ApplicationServiceProfile IOC), NgnSuMCredentials lOCs, IMSPubHcIdentification 
IOCS 


SuM Info Model related Outputs 


None identified 



Operation 


RP-SS Read Subscription Services 


Description 


Read subscription and user information related to IMS services and Application 
services 


Pre-conditions 


Subscriber, user and user service profiles exist 


Post-conditions 


No modification 


SuM Info Model related Inputs 


SuMUserlOC, SumServiceProfile lOCs (IMSServiceProfile IOC, 
ApplicationServiceProfile IOC), UserServicelnstance lOCs, NgnSuMCredentials 
IOCS, IMSPubHcIdentification IOC 


SuM Info Model related Outputs 


SumServiceProfile IOC (IMS ServiceProfile IOC, ApplicationServiceProfile IOC), 
User Servicelnstance IOC, NgnSuMCredentials IOC, IMSPubHcIdentification IOC 
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7.2 User Preferences (RP-UP) 

The RP-UP NOSI is dealing with the following part of the SuM Info model: 

• UserServicelnstance lOCs, IMSServiceProfile IOC, ApplicationServiceProfiles IOC. 



Operation 


RP-UP Configure preferences for user 


Description 


Configure user preferences in IIVIS services and Application services 


Pre-conditions 


Subscriber, subscription with subscribed services, user, user service profiles exist 


Post-conditions 


The preferences for the user have been configured 


SulVI Info IVIodel related Inputs 


SuMUser IOC, UserServicelnstance lOCs and possibly SumServiceProfile IOC 
(IMSServiceProfile IOC, ApplicationServiceProfile IOC) 


SuM Info Model related Outputs 


None identified 




Operation 


RP-UP Remove preferences for user 


Description 


Remove user preferences in IMS services and Application services 


Pre-conditions 


Subscriber, subscription with subscribed services, user, user service profiles exist 


Post-conditions 


The preferences for the user have been removed 


SuM Info Model related Inputs 


SuMuser IOC, UserServicelnstance lOCs and possibly SumServiceProfilelOC 
(IMSServiceProfilelOC, ApplicationServiceProfile IOC) 


SuM Info Model related Outputs 


None identified 




Operation 


RP-UP Update preferences for user 


Description 


Update user preferences in IMS services and Application services 


Pre-conditions 


Subscriber, subscription with subscribed services, user, user service profiles exist 


Post-conditions 


The user preferences have been updated 


SuM Info Model related Inputs 


SuMuserlOC, UserServicelnstance lOCs and possibly SumServiceProfile IOC 
(IMSServiceProfile IOC, ApplicationServiceProfile IOC) 


SuM Info Model related Outputs 


None identified 




Operation 


RP-UP Read preferences for user 


Description 


Read user preferences in IMS services and Application services 


Pre-conditions 


Subscriber, subscription with subscribed services, user, user service profiles exist 


Post-conditions 


No modification 


SuM Info Model related Inputs 


SuMUser IOC, UserServicelnstance IOC and possibly SumServiceProfile IOC 
(IMSServiceProfile IOC, ApplicationServiceProfile IOC) 


SuM Info Model related Outputs 


UserServicelnstance lOCs and possibly SumServiceProfile IOC (IMSServiceProfile 
IOC, ApplicationServiceProfile IOC) 



7.3 Subscription Network Access (RP- SNA) 

The RP-SNA NOSI is dealing with the following part of the SuM Info model: 

• NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLocation IOC, NgnLogicalAccess. 

• NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfile IOC. 



Operation 


RP-SNA Configure Network Access for user/subscription 


Description 


Configure subscription and user information of a TISPAN Network Access (NASS) 


Pre-conditions 


Subscriber, subscription with a Network Access subscribed service exists 


Post-conditions 


The subscription and user information of a TISPAN Network Access (NASS) has 
been configured 


SulVI Info Model related Inputs 


NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLogicalAccess 
SuMUser IOC (NASSUser), NgnNetworkAccessProfile IOC, 
NgnNetworkAccessSubProfile IOC 


SuM Info Model related Outputs 


None identified 
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Operation 


RP- SNA Remove Network Access for user/subscription 


Description 


Remove subscription and user information of a TISPAN Network Access (NASS) 


Pre-conditions 


The concerned TISPAN Network Access (NASS) and its configuration exists 


Post-conditions 


The subscription and user information of a TISPAN Network Access (NASS) has 
been removed 


SulVI Info IVIodel related Inputs 


NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLogicalAccess 
SulVIUser IOC (NASSUser), NgnNetworkAccessProfile IOC, 
NgnNetworkAccessSubProfile IOC 


SuM Info Model related Outputs 


None identified 




Operation 


RP- SNA Update Network Access for user/subscription 


Description 


Update subscription and user information of a TISPAN Network Access (NASS) 


Pre-conditions 


The concerned TISPAN Network Access (NASS) and its configuration exists 


Post-conditions 


The subscription and user information of a TISPAN Network Access (NASS) has 
been updated 


SuM Info Model related Inputs 


NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLogicalAccess 
SulVIUser IOC (NASSUser), NgnNetworkAccessProfile IOC, 
NgnNetworkAccessSubProfile IOC 


SuM Info Model related Outputs 


None identified 




Operation 


RP- SNA Read Network Access for user/subscription 


Description 


Read subscription information and user of a TISPAN Network Access (NASS) 


Pre-conditions 


The concerned TISPAN Network Access (NASS) and its configuration exists 


Post-conditions 


No modification 


SuM Info Model related Inputs 


NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLogicalAccess 

IOC 

SuMUser IOC (NASSUser), NgnNetworkAccessProfile IOC, 

NgnNetworkAccessSubProfile IOC 


SuM Info Model related Outputs 


NgnSubscribedNetworkAccess IOC, NgnPhysical Access IOC, NgnLogicalAccess 
NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfile IOC 





8 



SuM NGN Functional entities NOSIs 



This clause contains the description of the SuM NGN Functional entities NOSIs identified in clause 5.1. 

The NGN FE-MD NOSIs are dealing with the following part of the SuM Info model: 

For UPSF: IMSUserProfile lOCs, NgnSuMCredentials lOCs, IMSPublicIdentification lOCs, IFC lOCs, 
IRSET lOCs and relevant Ids. 

ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on the UPSF). 

For AS: ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on AS). 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC. 

For CLF: NgnPhysicalAccess IOC, NgnLocationlOC, NGNLogicalAccess IOC. 

NOTE: The NGN FE NOSIs support the same type of operations with the different NGN FEs (UPSF, PDBF, 
CLF, AS), but the transferred data are different from a NGN FE to another. 
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Operation 


NGN FE-MD Create Data 


Description 


Create Data in a NGN FE (UPSF, AS, PDBF, CLF) 


Pre-conditions 


The concerned data do not exist in the concerned NGN FE 


Post-conditions 


The concerned data have been created in the concerned NGN FE 


SulVI Info IVIodel related Inputs 


For UPSF: llVISServiceProfile lOCs, NgnSulVICredentials lOCs, 

IMSPublicldentification lOCs, IFC lOCs, IRSET lOCs 

ApplicationServiceProfiles IOC, UserServicelnstance IOC (when stored on the 

UPSF) 

For AS: ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on 

AS) 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC 

For CLF: NgnPhysicalAccess IOC, NGNLogicalAccess IOC 


SuM Info Model related Outputs 


None identified 



Operation 


NGN FE-MD Delete Data 


Description 


Delete Data in a NGN FE (UPSF, AS, PDBF, CLF) 


Pre-conditions 


The concerned data exists in the concerned NGN FE 


Post-conditions 


The concerned data have been deleted in the concerned NGN FE 


SuM Info Model related Inputs 


For UPSF: IMSServiceProfile lOCs, NgnSuMCredentials lOCs, 

IMSPublicldentification lOCs, IFC lOCs, IRSET lOCs, ApplicationServiceProfile 

lOCs, UserServicelnstance IOC (when stored on the UPSF) 

For AS: ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on 

AS) 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC 

For CLF: NgnPhysicalAccess IOC, NgnLocationlOC, NGNLogicalAccess IOC 


SuM Info Model related Outputs 


None identified 



Operation 


NGN FE-MD Update Data 


Description 


Update Data in a NGN FE (UPSF, AS, PDBF, CLF) 


Pre-conditions 


The concerned data exists in the concerned NGN FE 


Post-conditions 


The concerned data have been updated in the concerned NGN FE 


SuM Info Model related Inputs 


For UPSF: IMSServiceProfile lOCs, NgnSuMCredentials lOCs, 

IMSPublicldentification lOCs, IFC lOCs, IRSET lOCs, and relevant Ids 

ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on the 

UPSF) 

For AS: ApplicationServiceProfile lOCs, UserService-lnstance IOC (when stored on 

AS) 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC 

For CLF: NgnPhysicalAccess IOC, NgnLocationlOC, NGNLogicalAccess IOC 


SuM Info Model related Outputs 


None identified 



Operation 


NGN FE-MD Read Data 


Description 


Read Data in a NGN FE (UPSF, AS, PDBF, CLF) 


Pre-conditions 


The concerned data exists in the concerned NGN FE 


Post-conditions 


No modification 


SuM Info Model related Inputs 


For UPSF: IMSServiceProfile lOCs, NgnSuMCredentials lOCs, 

IMSPublicldentification lOCs, IFC lOCs, IRSET lOCs 

ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on the 

UPSF) 

For AS: ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on 

AS) 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC 

For CLF: NgnPhysicalAccess IOC, NGNLogicalAccess IOC 


SuM Info Model related Outputs 


For UPSF: IMSServiceProfile lOCs, NgnSuMCredentials lOCs, 

IMSPublicldentification lOCs, IFC lOCs, IRSET lOCs 

ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on the 

UPSF) 

For AS: ApplicationServiceProfile lOCs, UserServicelnstance IOC (when stored on 

AS) 

For PDBF: NgnNetworkAccessProfile IOC, NgnNetworkAccessSubProfilelOC 

For CLF: NgnPhysicalAccess IOC, NGNLogicalAccess IOC 
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Annex A (informative): 

Relation with 3GPP Generic User Profile (GUP) 



A.1 3GPP GUP Overview 



The objective of 3GPP Generic User Profile (GUP) [4], [5], [6], [7] is to provide means to enable harmonized usage of 
the user-related information originating from different entities, and allow extensibility to cater for future developments. 

The 3GPP Generic User Profile: 

• Is a Collection of User-related data. 

• Can be stored in the home network environment and/or Value Added Service Provider equipment. 

• Can be accessed by different stakeholders and managed either by one (centralized) or by different stakeholders 
(de-centralized) such as the user, subscriber, value added service provider and network operator by a 
standardized access mechanism. 

• Allows intra-network usage (i.e. data exchange between applications within a mobile operator's network) and 
inter-network usage (between mobile operator's network and value added service providers). 

• May be also be used by different applications in a standardized way. 
The 3 GPP Generic User Profile consists in the following technical aspects: 

• Architecture + Information Model. 

• Data Description. 

• Interface with mechanisms to handle the data. 

A. 1.1 Architecture 

The GUP Architecture as depicted in the figure consists of: 

• GUP Server: functional entity providing a single point of access to the Generic User Profile data of a 
particular subscriber. The GUP Server may be located in the home operator network of the targeted subscriber. 
The GUP Server includes the following functionalities: 

Single point of access for reading and managing generic user profile data of a particular subscriber. 

Location of Profile Components. 

Authentication of profile requests. 

Authorization of profile requests. 

Synchronization of Profile Components. 

• Repository Access Function (RAF): realizes the harmonized access interface. It hides the implementation 
details of the data repositories from the GUP infrastructure. 

• GUP Data Repositories: Each GUP Data Repository stores the primary master copy of one or several profile 
components. The RAF provides for the standardized access to the GUP Data Repository. 



ETSI 



23 



ETSI TS 188 002-3 V2.0.0 (2008-03) 



Rg and Rp reference points: The Rg reference points may allow applications to create, read, modify and 
delete any user profile data using the harmonized access interface. The Rp reference point may allow the GUP 
Server or applications, excluding external applications (e.g. located in a third party application or in the UE), 
to create, read, modify and delete user profile data using the harmonized access interface. Rp is an intra- 
operator reference point. 

Applications: The applications that may apply GUP reference points Rg and Rp may be targeted for different 
purposes e.g. for value added services or subscription management. Both operator's own applications and third 
party applications are covered. 



Application in 
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Figure A.1 : An example of mapping the GUP reference architecture 
to current infrastructure environment 



A.1 .2 Information Model 

A Generic User Profile consists of a number of independent GUP Components. However, a GUP Component may 
contain (i.e. reference) other GUP components e.g. to enable reuse of data. The GUP Component has a unique identity 
within the Generic User Profile. In addition to the component type the component identity contains either a subscriber 
identity or more generic identification depending on which kind of component is in question. A GUP Component can be 
retrieved through one RAF, and it may consist of a number of GUP Components, Data Element Groups and/or Data 
Elements. The UML Class Diagram below illustrates the basic concepts of the GUP Information Model. 
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Figure A.2: Example of the structure of GUP information 

A. 1.3 Interfaces 

Communication between GUP entities is performed via the exchange of messages expressed as XML documents. XML 
documents should include the XML declaration with the version and encoding attributes. The XML documents may be 
well-formed and valid. The W3C XML Schema is used in GUP to define the structure of valid XML documents. The 
implementation of the Rp and Rg interfaces follows the Liberty Alliance Data Service Template specification [Liberty 
Alliance] . 

The GUP interfaces and procedures are SOAP protocol based. Each interface is defined in terms of the messages sent 
and received. The payload of each message is XML, defined using an XML schema language. The framework, 
procedures, SOAP binding and security solutions of GUP are based on the Liberty Alliance Project work. 

The definition of the interfaces can be divided into the following sections: 

• Definition of the operations (WSDL/XML). 

• Common functions like security, authentication and authorization (WSDL/XML). 

• Repository Access Function specific data contents for the operations (XML Schema). 



A.1 .4 Data Description Method 



The Data Description Method can be viewed as a set of templates for constructing the data description. The templates 
(sets of rules) enable the standardization of the data description such that it and the described data can be shared (used) 
by many applications. The data descriptions are abstract in the sense that the data are described independently of data 
formats specific to data storage, transport protocols or application technologies. Abstraction of data descriptions 
simplifies the mapping between different data formats, and facilitates future extensions. 

The common use of the Data Description Method will avoid incompatibilities and inconsistencies between different 
Profile Components. 
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A.2 3GPP GUP and TISPAN SuM Functional 
Architecture 

This clause analyses the possible reuse of 3 GPP GUP Standards for TISPAN SuM Functional Architecture when 
considering: 

• The commonalities regarding requirements for GUP or TISPAN SuM Functional Architecture (Stage 1). 

• The commonalities regarding the architecture for GUP or for SuM (Stage 2). 

• The commonalities regarding the solutions sets (Stage 3). 

A.2.1 Commonalities regarding requirements 

Without going into a detailed analysis of GUP requirements as defined in TS 122 240 [4], this clause indicates many 
points where GUP objectives and requirements map to those of TISPAN SUM. 

TS 122 240 [4], clause 4.1, in its introduction mentions: 

• The objective of specifying the 3 GPP Generic User Profile is to provide a means to enable harmonized usage 
of the user-related information originating from different entities 

• The 3 GPP Generic User Profile is the collection of User-related data which affects the way in which an 
individual user experiences services where a community of entities share this data. The 3GPP Generic User 
Profile can be stored in the home network environment and/or Value Added Service Provider equipment. 

• The 3 GPP Generic User Profile will be accessed by different stakeholders and managed either by one 
(centralized) or by different stakeholders (de-centralized) such as the user, subscriber, value added service 
provider and network operator by a standardized access mechanism. (....) 

• The 3 GPP Generic User Profile may be also be used by different applications in a standardized way. 

• The 3 GPP Generic User Profile will help to create and manage the user data in each entity and on the other 
hand to make it easier to find all user related data as a whole in the home network environment. 

These GUP objectives maps with TISPAN SUM ones as they focus on user related data that are distributed on different 
entities. They are accessed by different stakeholders (user, subscriber, service provider) that have also been identified as 
such in the SuM requirements. It also addresses the user data related to applications that constitute an important part of 
SuM. Its design allows the creation and the management of user data distributed over different entities. 

General way to access user data 

It should be noted that GUP can be used in other areas than Subscription Management, as it allows access to user data 
stored in an entity by other entities (e.g. when different applications cooperate, they may access to user data stored or 
managed by another one, also when a third party application need to access user data stored in the operator network, 
with relevant access rights). GUP is a general way to access and manage user data. In a GUP environment. Subscription 
Management is one process among others that have to access user data. It seems important to avoid to develop two 
interfaces to access user data, one dedicated to Subscription Management, one used for other applications. 

Support of Applications in particular with non standardized services 

TS 122 240 [4], clause 4.1.2, explicitly mentions that: 

• Subscription Management benefits from a standardized way to access subscription data of a user. 

• (....) new services in 3 GPP are not standardized. Therefore content and format of subscription data as well as 
the places (repositories) where subscription data are stored may be different for different new services. GUP 
specifies the description of - and access of data in a standardized way. 
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It should be noted that GUP addresses non standardized services, by defining a minimum set of rules allowing to 
describe and access data in a standardized way. It allows to introduce new applications with their specific user data in a 
flexible way without impacting other entities. It corresponds to a SuM objective to support provisioning of NGN 
Services including those, non standardized, offered by Application Servers. 

Synchronization of data 

TS 122 240 [4], clauses 4.4 and 6.5, identifies the need to keep synchronized GUP data components stored in different 
repositories, that SuM functional Architecture has also to address. 

Stakeholder requirements 

TS 122 240 [4], clause 5, describes requirements regarding stakeholders quite close to the TISPAN SuM ones: 

• The subscriber may hold subscriptions for one user (..;) or several users (...) 

• The subscriber may be able to customize her subscribed services and interrogate customization settings, 
subject to limitations by the Home operator and/or value added service provider. (. . .) 

• The user may be able to customize the services, that have been subscribed to her by the subscriber and 
interrogate customization settings, subject to limitations by the Home operator and/or value added service 
provider and/or subscriber. 

General Service Requirements 

TS 122 240 [4], clause 6.3, mentions: 

It may be possible for an application to retrieve the whole user profile or selected parts of it in one transaction. 

A.2.2 Commonalities regarding Architecture (Stage 2) 

Reference points Rp and Rg 

The reference Architecture of TS 123 240 [5] describes two reference points Rp and Rg that fit with the reference points 
(NOSIs) identified in the SUM Functional Architecture: 

• 3GPP GUP Rp corresponds to the NGN FE NOSI. Both are used to access and manage the user data stored on 
NGN FE. 

• 3GPP GUP Rg corresponds to the RP NOSIs, that hide the network topology, offer a single point of access and 
allow synchronization of profile components. 

Repository Access Function (RAF) 

The RAF function realizes the harmonized Rp access interface. It hides the implementation details of the data 
repositories from the GUP infrastructure real. It correspond to the fact that in SuM Functional Architecture, NGN FEs 
should expose NOSIs with the same characteristics to access the data, regarding the operations and the way to structure 
the data, the difference being in the data themselves that are specific to each type of NGN FE. 

Structure of data 

The SuM Functional Architecture should support a large variety of user profiles, dependent of the NGN services 
offered, in particular from applications servers. There is the need to structure the user data by grouping them in 
independent components. The word "independent" is important, as when adding a new application with its own user 
profiles, it should not impact the user data of other applications and avoid incompatibilities. 

TS 123 240 [5], clause 5 defines an info model, and TR 123 941 [6], a Data Description Method that describes a way to 
structure the data in GUP components to answer the same type of requirement as for SuM. The GUP component 
concept allow the independence of applications and their user profiles and offer the way to process these components 
individually. 
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Operations 



The operations that TS 123 240 [5] describes for Rp and Rg interfaces (Create, Delete, Modify, Query, Subscribe, 
Notify) corresponds to the operations defined respectively for NGN FE NOSIS and RP NOSIs. Able to contain several 
data components, they allow data synchronization within one data repository or several. 

A.2.3 Commonalities regarding Solution Sets (Stage 3) 

The TISPAN SuM functional architecture does not address stage 3 specifications, it is nevertheless worthwhile to note a 
certain number of Stage 3 GUP characteristics that are of interest for SuM. 

3 GPP GUP stage 3 relies on: 

• Web services described by wsdl files. 

• Data structure described through XML data scheme (xsd) files. 

• Liberty Alliance standards in particular for the definition of operations. 

• use of different name spaces guaranteeing independence of the user profiles. 

• use of a subset of Xpath language to retrieve the components. 

The use of Web Services is conform to the TISPAN OSS Architecture for NGN Management [1]. 
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Annex B (informative): 

Relation with 3GPP Integration Reference Points (IRPs) 

B.1 3GPP IRP Introduction and overview 

References: TS 132 101 [11] and 132 150 [12]. 

IRP (Integration Reference Point): an architectural concept that is described by a set of specifications for definition of 
a certain aspect of a management interface, comprising a Requirements specification, an IRP Information Service 
specification, and one or more IRP Solution Set specifications. 

For the purpose of management interface development 3GPP has developed an interface concept known as Integration 
Reference Point (IRP) to promote the wider adoption of standardized management interfaces in telecommunication 
networks. The IRP concept and associated methodology employs protocol and technology neutral modelling methods as 
well as protocol specific solution sets to achieve its goals. 

B.1.1 General 

The three cornerstones of the IRP concept are: 

• Top-down, process-driven modelling approach: The purpose of each IRP is automation of one specific task, 
related to TMF TOM. This allows taking a "one step at a time" approach with a focus on the most important 
tasks. 

• Technology-independent modelling: To create from the requirements an interface technology independent 
model. This is specified in the IRP Information Service. 

• Standards-based technology-dependent modelling: To create one or more interface technology dependent 
models from the technology independent model. This is specified in the IRP Solution Set(s). 



IRP REQUIREMENTS 



IRP INFORMATION SERVICE 

4 




1 



IRP SOLUTION SETS 



CMIP 



Figure B.1 : IRP components (with example Solution Sets; for definition of 
valid 3GPP Solution Sets, see annex C in TS 188 001 [1]) 
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B.1 .2 IRP Specifications Approach 



As highlighted in the previous clause, IRP specifications are specified using a 3-level approach: Requirements, 
IS-level and SS-level. 

Furthermore, there are three categories of IRP specifications (see formal and more detailed definitions in clause 3.1): 

• Interface IRPs. 

• NRM IRPs. 

• Data Definition IRPs. 

Each category is partitioned into Requirements, IS-level and SS-level specifications. 



Requirements/ Use Cases 



Interface IRP's 



NRM IRP's 



Data 
Definition IRP's 



Information Service Definitions (UML) 



• Notification IRP 


• Generic NRM 


• Alarm IRP 


• CoreNWNRM 


• BulkCM IRP 


• UMTS NRM's 


• KernelCM IRP 


• CDMA NRM's 


• BasicCM IRP 


• Inventory NRM 


• etc 


• etc 



•State MgmtIRP 
• etc 



/gy. ^ Relative stable 

( ^ I over long 

\/ period of time 



/gMi ■ Changes only with 

( ^ I respect to addition 
^i and extensions 



Solution Set Definitions (CORBA, SOAP, XIVIL, CMiP) 
Solution Set Definitions (other/future e.g. JAVA , SNMP) 



Co 



Changes with 

new/better 

Technologies 



Figure B.2: The IRP 3-Level Specifications Approacli combined witli the three IRP categories 

Level 1: 

The "Requirements-level" intends to provide conceptual and use cases definitions for a specific management 
interface aspect as well as defining subsequent requirements for this IRP. 



Level 2: 



The "IS-level" provides the technology independent specification of an IRP. 



Level 3: 



The "SS-level" finally provides the mapping of IS definitions into one or more technology-specific Solution 
Sets. This concept provides support for multiple interface technologies as applicable on a vendor and/or 
network type basis and also enables accommodation of future interface technologies - without the need to 
redefine requirements and IS-level definitions. 
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B.2 Architecture 



The 3 GPP IRPs were originally developed to support the management interfaces Itf-N and Itf-P2P in the following 
reference architecture: 



Organization A 




Organization B 



Figure B.3: 3GPP management reference model 

However, due to a more generalized definition of the IRP, as seen in the first paragraph of clause B.l, the IRP concept 
and interface specifications are today applicable to any management interface or reference point, e.g. management 
interfaces/NOSIs defined by TISPAN, both the SCA layer, the RP layer as well as the NGN FE layer. As can be seen in 
figure B.l, those layers also have many similarities with the various scenarios for 3 GPP management interface 2. 



B.3 IRP SOAP Solution Sets 

The 3GPP IRP specifications of the table below are supported by SOAP Solution Sets which were created in particular 
for SuM in 3GPP. These IRPs are described here as candidates for reuse by TISPAN within SuM NOSIs, not excluding 
the possible relevance of other 3GPP IRPs. 

The Requirements, Information Service (IS) and SOAP Solution Sets of the Interface IRPs for 3GPP SuM are the listed 
below. 

The Requirements, Information Service (IS) and XML file format/schema definitions of the NRM IRPs for 3GPP SuM 
are also listed below. 

3GPP identifies system contexts of the Interface IRP in terms of its implementation, called IRP Agent, and the user of 
the IRP Agent, called IRPManager. These terms are used in the subsequent clauses. 
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IRP short name 


Part 


Number, Title 


Generic IRP 


Requirements 


TS 132 311 : Generic Integration Reference Point (IRP) management: Requirements 
f131 


IS 


TS 132 312: Generic Integration Reference Point (IRP) management: Information 
Service (IS) [14] 


SOAP 


TS 132 317: Generic Integration Reference Point (IRP) management; SOAP 
solution set [15] 


Notification IRP 


Requirements 


TS 132 301 : Configuration Management (CM); Notification Integration Reference 
Point (IRP): Requirements [16] 


IS 


TS 132 302: Configuration Management (CM); Notification Integration Reference 
Point (IRP): Information Service (IS) [17] 


SOAP 


TS 132 307: Configuration Management (CM); Notification Integration Reference 
Point (IRP): SOAP solution set [18] 


Kernel CM IRP 


Requirements 


TS 132 661 : Configuration Management (CM); Kernel CM Requirements [19] 


IS 


TS 132 662: Configuration Management (CM); Kernel CM Information 
Service (IS) [20] 


XML 


TS 132 665: Configuration Management (CM); Kernel CM Integration Reference 
Point (IRP): extensible Markup Language (XML) definitions [21] 


SOAP 


TS 132 667: Configuration Management (CM); Kernel CM Integration Reference 
Point (IRP): SOAP solution set [22] 


Basic CIVI IRP 


Requirements 


TS 132 601 : Configuration Management (CM); Basic CM Integration Reference Point 
(IRP): Requirements [23] 


IS 


TS 132 602: Configuration Management (CM); Basic CM Integration Reference Point 
(IRP): Information Service (IS) [24] 


SOAP 


TS 132 607: Configuration Management (CM); Basic CM Integration Reference Point 
(IRP): SOAP solution set [25] 


Generic NRIVI 
IRP 


Requirements 


TS 132 621 : Configuration Management (CM); Generic network resources 
Integration Reference Point (IRP); Requirements [26] 


IS 


TS 132 622: Configuration Management (CM); Generic network resources 
Integration Reference Point (IRP); Network Resource Model (NRM) [27] 


XML 


TS 132 625: Configuration Management (CM); Generic network resources 
Integration Reference Point (IRP); Bulk CM extensible Markup Language (XML) file 
format definition [28] 


SuMNRMIRP 


Requirements 


TS 132 171 : Subscription Management (SuM) Network Resource Model (NRM) 
Integration Reference Point (IRP): Requirements [8] 


IS 


3GPP TS 32.172: Subscription Management (SuM) Network Resource Model (NRM) 
Integration Reference Point (IRP): Information Service (IS) [9] 


XML 


TS 132 175: Subscription Management (SuM) Network Resource Model (NRM) 
Integration Reference Point (IRP): extensible Markup Language (XML) definition [10] 



B.4 Overview of IRPs related to SOAP SSs 



B.4.1 Generic IRP 

Tlie Generic IRP (ETSI TS 132 31x) defines some generic data and operations used by all Interface IRPs. Therefore, 
this IRP is necessary to reuse when reusing Interface IRPs. 

B.4.2 Notification IRP 

The Notification IRP (ETSI TS 132 30x) provides basic definitions and operations to send notifications. The basic idea 
is that an IRPManager subscribes to notifications of events sent by an IRP Agent, where the trigger condition for 
sending the notification is specified during establishment of the subscription. 

The operations to manage establishment and modification of a subscription to notifications includes: 

• subscribe, unsubscribe: To subscribe and unsubscribe to notifications. 

• other operations to manage the subscription, such as changing the trigger condition, inquiring status, and 
suspend/resume. 
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B.4.3 Kernel CM IRP 

The Kernel CM (Configuration Management) IRP (ETSI TS 132 66x) defines operations and notifications for 
Configuration Management. 

The following operation is specified: 

• getNRMIRPVersion: Used by an IRPManager to obtain the version(s) of the NRM IRP supported by the 
IRPAgent. 

The notifications are the following: 

• notifyObjectCreation, notifyObjectDeletion: To notify creation and deletion of objects. 

• notif yAttributeValueChange: To notify change of attribute value(s). 

• not if yCMSynchronizat ionRecommended: To notify a recommendation of synchronizing of data. 

• not if yStateChange: To notify a state or status change of an object. 

B.4.4 Basic CM IRP 

The Basic CM IRP (ETSI TS 132 60x) defines operations on Managed Object instances of a MIB (i.e. object instances 
of lOCs) defined by an NRM IRP. The information of the Managed Object instances and the attributes are transferred 
as part of the operations. 

The operations are the following: 

getMoAt tributes: To read attribute values of Managed Object instances. Scope/filter criteria may be 
specified, and this allows for a large variety of possibilities in selecting objects and attributes subject to read. 

get Containment: To retrieve (name-)containment relations in the MIB. 

cancelOperation: To cancel an ongoing Basic CM operation. 

createMO: To create a Managed Object instance. In this operation it is also possible to specify attribute 
values. 

deleteMO: To delete one or more Managed Object instances. 

setMOAt tributes: To set attributes of Managed Object instances. Attributes of one or several Managed 
Objects may be modified - based on the containment hierarchy and scope/filter criteria. 

B.4.5 Generic NRM IRP 

The Generic NRM IRP (ETSI TS 132 62x) specifies Information Object Classes (lOCs), attributes, relationships, etc., 
used by both Interface IRPs and other NRM IRPs. 

B.4.6 SuM NRM IRP 

The SuM NRM IRP IS (3GPP TS 32.172 [9]) is used as basis for the TISPAN SuM Information Model 

(TS 188 002-2 [3]). The XML file format definition is extendable to cover also the TISPAN specific parts of the model. 
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B.5 3GPP IRPs and TISPAN SuM Functional 
Architecture 

This clause analyses the possible reuse of 3 GPP IRPs for TISPAN SuM Functional Architecture when considering: 

• the commonalities regarding requirements for IRPs and TISPAN SuM Functional Architecture (Stage 1); 

• the commonalities regarding the architecture and information models for IRPs and for SuM (Stage 2); 

• the commonalities regarding the solution sets (Stage 3). 

B.5.1 Commonalities regarding requirements (Stage 1) 
B.5.1.1 General 

• The 3GPPs IRPs were developed to support (any) management interfaces, with CMISE/CRUD-like operations 
accessing/manipulating data defined in object-oriented information models. 

• Interface IRPs and NRM IRPs can be accessed by any entity acting as an IRPManager, which also includes a 
TISPAN NOSI consumer (in case the NOSI is defined to access an IRP interface). 

B.5.1 .2 IRP support of SuM FA requirements in TS 1 88 002-1 

The following table gives a high-level overview of the SuM requirements on Functional Architecture in 

TS 188 002-1 [2], clause 6.3, and whether a reuse of the 3GPP SuM NRM IRP (ETSI TS 132 17x) and corresponding 

SOAP SSs for Interface IRPs support each requirement or not. 
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Requirement 


IRP support 


Comment 


R1) The SuM functional architecture may 
hide the complexity of the different functional 
entities to be configured including the CPE 
and the AS. 


Yes 


The SuM NRM IRP and extensions in the TISPAN SuM 
IM only model the lOCs and attributes etc., necessary 
for management. 


R2) The SuM functional architecture may 
allow management of necessary/optional 
data, operations and notifications related to 
Subscription Management. 


Yes 


Supported by 3GPP SuM NRM IRP (ETSI TS 132 17x) 
with TISPAN extensions, and corresponding SOAP SSs 
for Interface IRPs. 


R3) The SuM functional architecture may be 
easily extensible for the support of new 
operations, data, and notifications. 


Yes 


Supported by TISPAN extensions to the reused 3GPP 
IRPs. 


R4) The SuM functional architecture may 
define the NGN OSS Service Interfaces for 
the realization of the following processes: 

SM&O Service Configuration and 

Activation process. 

RM&O Resource Provisioning process. 


Yes 


Supported if the TISPAN NOSIs access relevant objects 
and data in the TISPAN SuM IM based on the 3GPP 
SuM NRM and related SOAP SSs. 


R5) The NOSIs related to Service 
Configuration & Activation may be network 
technology agnostic without any knowledge 
of the NGN functional entities that are 
involved. 


Yes 


The TISPAN SuM IM and 3GPP SuM NRM are network 
technology agnostic. 


R6) The NOSIs related to Resource 
Provisioning are responsible of NGN 
functional entities (including CPE and AS) 
management and may hide the complexity of 
the different NGN functional entities to the 
NOSIs related to Service Configuration and 
Activation. 


Yes 


See comment to R1 above. 


R7) The NOSIs related to Service 
Configuration and Activation may manage 
the configuration of new subscription, and 
support of the reconfiguration of installed 
subscription (either due to customer demand 
or problem resolution). 


Yes 


Supported by normal management operations 
(Create/Delete instance. Set attributes etc.) to/by the 
NOSIs accessing TISPAN SuM IM (based on 3GPP 
SuM NRM) or a more high-level operation. Such 
operations may be ordered directly by the NOSI 
consumer or generated by the NGN OSS Service itself 
as a result of a more high-level operation request. 


R8) the SuM Functional Architecture may 
comply with the eTOM Operation regarding 
Fulfilment as described in clause 4.2 with the 
following processes. 


To be verified 


This is most likely also supported by 3GPP IRP reuse, 
or at least not hindered by IRP reuse. There is ongoing 
work in 3GPP SA5 to update the high-level 
requirements in TS 1 32 1 01 [11] and corresponding IRP 
specifications as necessary to be in line with eTOM. 


R9) The SuM functional architecture should 
consider reuse as much as possible of 3GPP 
existing standards. 


Yes 





B.5.2 Commonalities regarding the architecture and information 
models (Stage 2) 

B.5.2.1 General 

• Interface IRPs are separated from, and independent of, the information model managed over the interface and 
thus can be used to manage any object-oriented information model. 

• The Generic NRM (TS 132 622 [27]) and SuM NRM (3GPP TS 32.172 [9]) are already being reused for the 
core part of the TISPAN SuM IM. 
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B.5.2.2 Reference points 



As mentioned in clause B.2, due to the general definition of the IRP, the IRP concept and interface specifications are 
today applicable to any management interface or reference point, e.g. management interfaces defined by TISPAN (note: 
the TISPAN OSS architecture does NOT define any reference points). Thus, this supports the "loose coupling" between 
entities which is required for service management interfaces. 

The following diagram depicts various alternative scenarios with IRPManagers and an NGN OSS Service accessing 
various NOSIs, the latter acting as IRP Agents. 




( ( NOSI Consumer/ \ 
I I IRPManager J 




^^^ NOSI exposed for the management of data stored in NGN FE 

T 
T 

T 



RP NOSI 
SCA NOSI 



NGN OSS Basic Frameworic Services NOSIs 



NOSI acting as IRPAgent 



Figure B.4: NOSI scenarios with IRPManagers/ Agents 

B.5.2.3 Structure of data 

The IRP concept, and in particular the separation of Interface IRPs from NRM IRPs, allows any structure of data (and 
the relationships between data) to be managed._The implementation of the lOCs in the various NRM IRPs may be 
distributed arbitrarily throughout the network. 

B.5.2.4 Operations 

The operations that are defined by the various 3GPP Interface IRP specifications listed in B.3 above (Create, Delete, 
GetMo Attributes, SetMoAttributes, Subscribe, NotifyXyz) correspond to the operations defined respectively for all 
NOSIs (SCA, RP, NGN FE NOSIs). 



ETS\ 



36 ETSI TS 1 88 002-3 V2.0.0 (2008-03) 

B.5.3 Commonalities regarding Solution Sets (Stage 3) 

The TISPAN SuM functional architecture does not address stage 3 specifications, it is nevertheless worthwhile to note a 
certain number of 3GPP IRP SS characteristics that are of interest for SuM. 

3GPP IRP SOAP Solution Sets for SuM comprise: 

• The SS provides a clear mapping of the Stage 2 (ISs for Interface IRP and NRM IRP) to Stage 3 (SS) 
specifications, which is in line with the TISPAN WG8 specification guidelines. And since there are many 
commonalities on the Stage 2 level, this also provides for many commonalities on the Stage 3 level. 

• Web services described by wsdl files (the use of Web Services is compliant to the TISPAN OSS Architecture 
for NGN Management [1]). 

• Data structures described through XML data scheme (xsd) files of NRM IRPs. 

• 3 GPP uses name spaces for object instances as well as XSD schema that are perfectly reusable by TISPAN, 
thus guaranteeing globally unique identification of all IOC instances and XSD schema. 

• The SOAP Solution Sets support the XPath filter language (see W3C XPath 1.0 specification [29]). IRP Agents 
may throw a FilterComplexityLimit fault when a given filter is too complex. 



ETSI 



37 ETSI TS 1 88 002-3 V2.0.0 (2008-03) 



Annex C (informative): 
Bibliography 



ETSI TS 132 140: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Telecommunication management; Subscription Management (SuM) requirements 
(3GPPTS 32.140)". 

ETSI TS 132 141: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Telecommunication management; Subscription Management (SuM) architecture (3GPP TS 32.141)". 



ETSI 



38 



ETSI TS 188 002-3 V2.0.0 (2008-03) 



History 



Document history 


V2.0.0 


March 2008 


Publication 



























ETSI 



